Publish/subscribe data processing systems have become very popular in recent years as a way of distributing data messages. Publishers are not concerned with where their publications are going, and subscribers are not interested in where the messages they receive have come from. Instead, a message broker typically assures the integrity of the message source, and manages the distribution of the message according to the valid subscriptions registered in the broker.
FIG. 1 illustrates a typical publish/subscribe data processing system according to the prior art. A message broker 15 has an input mechanism 20 which may be, for example, an input queue or a synchronous input node by which messages are input when they are sent by a publisher 5; 10 to the message broker. A published message is fetched from the input mechanism by a controller 40 and processed to determine, amongst other things, to which subscribers 60; 65; 70 the message should be sent.
Message topics typically provide the key to the delivery of messages between publishers and subscribers. The broker attempts to match a topic string on a published message with a list of clients who have subscribed to receive publications including that topic string. A matching engine 30 is provided in the message broker for this very purpose. When the subscriber registers, it must typically specify a means by which it wants to receive messages (which may be a queue or other input mechanism) and a definition of the types of messages that it is interested in. A subscriber can specify, for example, that it wishes to receive messages including a topic string such as “employee/salary” and any messages matching that topic string will be identified and forwarded on to the subscriber via an output mechanism 50. (Note, there may be more than one input and output mechanism to and from which messages are received and sent by the message broker.)
Publishers and subscribers may also interact with a homogeneous network of brokers (in which each broker is a linked installation of the same product), each one of which propagates subscriptions and forwards publications to other brokers within the network. In this way the network of brokers may act as a single broker.
A publish/subscribe system may however comprise two messaging brokers (A and B) which may be installations of different products. With the help of bridging technology, it is also possible to join the two brokers together using only the public publisher and subscriber APIs in order to present a unified publish/subscribe messaging system in which subscribers attached to both brokers can receive publication messages unaware of the broker to which the publisher was connected. This allows the heterogeneous brokers to be viewed as a single messaging domain, which is a key goal of application integration technologies.
Messages published to either of the brokers may also include a topic on which a reply message should be published in order to be processed by the original publishing application. This is known as request/reply messaging. Like the topic on which the original message is published, the reply topic is defined in the original application, and so the administrator can examine the application code to determine which topic is being used for replies, and configure an appropriate topic mapping in the bridging application to enable the reply message to return to the correct side of the bridge to be processed by the requester.
It is not however possible to define this topic mapping if a temporary topic is being used as the reply topic. Temporary topics are a facility which may be provided by a messaging broker which dynamically generates a unique topic name to be used by the requesting application.
Temporary topics are normally used as reply destinations in situations where the requesting application:    (i) Cannot rely on the existence of a pre-defined resource (e.g. topic) that could be used to receive the response (a reduced configuration overhead).    (ii) Wishes to avoid other applications being able to receive the reply message (better security).    (iii) Wishes to avoid having to filter the response message from other messages published on the same topic (better efficiency).
The name of the temporary topic is not known until the point at which it is created, and the existence of the temporary topic lasts only until the requesting application is closed. Since the name of the temporary topic is not known in advance, it is not possible to predefine a topic mapping that would enable the reply message to return to the requesting application. Thus a response will never be received. This prevents the two brokers from being viewed as a single messaging domain since this basic operation will only work correctly if the requesting and responding applications are connected to the same broker.